Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

pgf clashes with bookmarks #944

Closed
u-fischer opened this issue Nov 6, 2020 · 6 comments
Closed

pgf clashes with bookmarks #944

u-fischer opened this issue Nov 6, 2020 · 6 comments
Labels
closed-wont-fix

Comments

@u-fischer
Copy link

u-fischer commented Nov 6, 2020 •
edited

Brief outline of the bug

As reported on tex.sx https://tex.stackexchange.com/questions/569700/conflict-between-tikz-and-bookmark-packages the bookmarks/outlines created by the bookmark package are lost on the latex-dvips-ps2pdf routed if pgf is loaded too.

I can reproduce this with a current texlive using the internal ghostscript (version 9.53.3). In texlive 2019 it works fine.

Minimal working example (MWE)

\documentclass{article}
\usepackage{tikz}
\usepackage{bookmark}

\begin{document}

\section{One section}

Some text

\newpage

\section{Another section}

Another text

\end{document}

The .ps contains the bookmarks code, but when processing it with ps2pdf they are lost.

I tracked the problem down to this code part in pgfsys-dvips.def (line 107ff):

   /.pushpdf14devicefilter where {pop
      [userdict /bop-hook known {userdict /bop-hook get aload pop} if
        {0 .pushpdf14devicefilter} aload pop] cvx userdict exch /bop-hook exch put
      [userdict /eop-hook known {userdict /eop-hook get aload pop} if
        {.poppdf14devicefilter} aload pop] cvx userdict exch /eop-hook exch put%
    } if

If one remove/comment this, the bookmarks reappears.

The ghostscript documentation says about this device filter:

Pushing the compositor device must be done before any other marking operations are made on the current page, and must be done per page. Popping the compositor should be done after the last marking operation of the page, and before the call to showpage. Any marking operations made after the compositor is popped will bypass the transparent imaging model, and may produce unexpected output.

My (rather wild) guess is that the source of the problem is that with bookmark the outlines are not created with pdfmark commands in the page stream (as hyperref does it), but with a ProcSet, and that this produces the "unexpected" output.
@hmenke
Copy link
Member

hmenke commented Nov 6, 2020

@agrahn

@agrahn
Copy link
Contributor

agrahn commented Nov 6, 2020

The ghostscript documentation says about this device filter:

Pushing the compositor device must be done before any other marking operations are made on the current page, and must be done per page. Popping the compositor should be done after the last marking operation of the page, and before the call to showpage. Any marking operations made after the compositor is popped will bypass the transparent imaging model, and may produce unexpected output.

For exactly that reason I added the 0 .pushpdf14devicefilter and .poppdf14devicefilter operators to the bop and eop hooks. I will look into this. Perhaps transparency still works without those.

@u-fischer
Copy link
Author

For exactly that reason I added the 0 .pushpdf14devicefilter and .poppdf14devicefilter operators to the bop and eop hooks. I will look into this. Perhaps transparency still works without those.

I made a small test with transparency, and it seemed to work without this code, but I wonder if the problem indicates that something is wrong with ghostscript or the bookmark code.

@agrahn
Copy link
Contributor

agrahn commented Nov 6, 2020 •
edited

@u-fischer

I would suggest the patch to bkm-dvips.def listed below.

The /OUT pdfmarks are read-in from \jobname.out.ps as an ordinary PS file using the PSfile special, rather than as a PS header file. This allows the pdfmarks for outlines to be placed at the end of the last document page to be shipped out, which is a perfect place for document-level stuff. This would resolve the reported issue.

--- bkm-dvips.def.orig	2020-11-06 14:51:12.383608024 +0100
+++ bkm-dvips.def	2020-11-06 14:52:32.586524468 +0100
@@ -60,10 +60,10 @@
 \ProvidesFile{bkm-dvips.def}%
   [2019/12/03 v1.28 bookmark driver for dvips (HO)]%
 \def\BKM@PSHeaderFile#1{%
-  \special{header=#1}%
+  \special{PSfile=#1}%
 }
 \def\BKM@filename{\jobname.out.ps}
-\BKM@PSHeaderFile\BKM@filename
+\AddToHook{shipout/lastpage}{\BKM@PSHeaderFile\BKM@filename}
 \RequirePackage{atveryend}[2009/12/07]
 \AfterLastShipout{\BKM@pdfmark@out}
 \def\BKM@pdfmark@out{%

@u-fischer
Copy link
Author

I have uploaded a bookmark version with the fix suggested by @agrahn. It should appear at ctan soon.

@hmenke
Copy link
Member

hmenke commented Nov 8, 2020

Thank you very much! I marked the issue as wont-fix because it wasn't fixed on the PGF side.

@u-fischer u-fischer mentioned this issue Mar 14, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
closed-wont-fix
Milestone
No milestone
Development

No branches or pull requests
3 participants
@agrahn @hmenke @u-fischer